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1.  Introduction 


Wireless  communications,  especially  with  satellite  networks,  tend  to  be  labeled  noisy,  highly 
delayed,  and  costly.  On  the  other  hand,  wireless  satellite  communications  provide  some  benefits 
such  as  convenience,  mobility,  and  flexibility  in  accessing  the  service.  In  some  cases,  it  is  cost 
effective  to  use  the  service  if  there  is  no  existing  communication  infrastructure  available.  There 
are  both  military  and  commercial  applications  that  use  the  digital  data  service  of  the  International 
Maritime  Satellite  (Inmarsat)  to  provide  a  wide  area  network  (WAN)  link  for  a  local  area 
network  (LAN)  to  the  home  LAN  from  almost  anywhere  on  the  earth,  except  areas  near  the  north 
and  south  poles.  The  communication  link  of  the  WAN  connection  is  achieved  through  the 
satellite  network  of  Inmarsat  and  a  land-earth  digital  telephone  network,  such  as  Integrated 
Services  Digital  Network  (ISDN).  To  determine  how  well  the  wireless  satellite  service  works, 
we  evaluated  the  throughput  rate  of  data  transmission  in  the  Transmission  Control 
Protocol/Intemal  Protocol  (TCP/IP)  environment  (which  is  used  by  the  IP  WAN)  over  the 
International  Maritime  Satellite  (Inmarsat)-ISDN  link  and  compared  it  with  the  throughput  data 
rate  over  a  null-modem  link  for  the  WAN  connection.  The  null-modem  link  is  assumed  to  be 
error  free.  In  addition,  we  also  used  the  protocol  boosters  [1]  that  provide  forward  error 
correction  for  the  TCP/IP  environment  to  test  the  improvement  of  data  transmission  over  the 
satellite  link.  As  expected,  the  forward  error  correction  will  improve  data  transmission  if  the 
bandwidth  used  for  forward  error  correction  is  less  than  the  bandwidth  used  for  retransmission 
due  to  error  on  the  link.  To  accurately  measure  the  TCP  and  user  datagram  protocol  (UDP) 
performance  over  IP  with  these  protocol  boosters,  we  used  the  software  Test  Transmission 
Contro  Protocol  (TTCP),  which  is  in  the  public  domain. 


2.  Background 


2.1  Inmarsat 

Inmarsat  is  the  communication  service  provided  by  the  International  Maritime  Satellite 
organization.  In  1979,  a  consortium  of  79  countries  established  the  Inmarsat  organization  to 
serve  the  maritime  industry.  The  organization  operates  and  governs  a  global  satellite  system 
consisting  of  four  satellites  in  geostationary  orbit  to  provide  voice,  fax,  analog  data,  and  digital 
data  communications  for  maritime  customers  on  the  move  or  in  remote  locations.  Today,  its 
function  has  expanded  to  include  services  for  land,  mobile,  and  aeronautical  communications 
along  with  personal  and  multimedia  mobile  satellite  communications.  Its  global  satellite  system 
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has  grown  to  nine  geostationary  satellites  to  provide  all  the  services  as  before  but  also  to  allow 
spares  or  leased  capacity  and  to  operate  a  number  of  spot  beam  “cells”  that  enable  the  satellites 
to  concentrate  extra  power  in  areas  of  high  demand  [2].  There  are  about  40  land-earth  stations 
(LES)  [2]  that  provide  communications  in  between  Inmarsat  satellites  or  between  Inmarsat 
satellites  and  land-earth  communication  networks. 

An  Inmarsat  communication  link  can  be  initiated  from  a  mobile  satellite  communication  unit 
(MSU)  by  transmitting  signals  to  a  satellite  of  the  Inmarsat  satellite  network.  Upon  receiving  the 
signals,  the  Inmarsat  satellite  transmits  them  to  an  LES  specified  by  the  initiator  MSU.  The  LES 
then  sends  the  signals  through  a  land-earth  telephone  network  to  a  destination  source  in  the 
telephone  network.  To  establish  a  digital  data  communication  link  with  an  MSU,  the  destination 
source  must  be  connected  to  a  land-earth  digital  phone  network,  such  as  an  ISDN.  A  regular 
phone  source  can  also  be  linked  to  an  MSU  by  reversing  this  process. 

In  our  experiment,  we  used  a  Rockwell  DATA*SAT  satellite  communications  (SATCOM)  unit 
with  the  “Inmarsat-B”  service  [3].  The  high-speed  digital  data  service  of  the  SATCOM  unit  used 
the  Inmarsat  satellite  AOR-W  (Atlantic  Ocean  -  West),  the  LES  of  COMSAT  Mobile 
Communications,  and  the  USA  national  ISDN  with  Worldcom/MCI  as  long  distance  carrier  and 
Verizon  as  local  carrier.  The  Inmarsat-B  service  can  provide  9.6-kbps  analog  communication 
(for  voice,  fax,  and  data)  and  high-speed  digital  data  communication  at  56/64-kbps  data  rate. 

2.2  Protocol  Boosters 

The  protocol  boosters  are  a  collection  of  parasitic  modules  (which  can  be  software  or  hardware) 
that  transparently  enhance  communication  protocols  [1].  The  boosters  can  reside  anywhere  in  the 
network,  operating  independently  in  one  network  node  (single  element  booster)  or  being 
distributed  over  several  network  nodes  (multi-element  booster).  They  can  add,  delete,  or  delay 
end-to-end  protocol  messages  but  never  modify  the  syntax  or  semantics  of  the  end-to-end 
protocol  message  exchanges.  The  insertion  or  removal  of  protocol  boosters  does  not  prevent  end- 
to-end  communications. 

In  the  experiment,  we  installed  the  protocol  boosters  developed  by  Telcordia  Technologies  on 
the  two  Linux  operating  systems  running  kernel  level  2.0.32.  The  two  primary  booster  modules 
used  in  the  experiment  were  forward  erasure  correction  (FZC)  and  packet  resizer  (MSS).  We 
also  used  the  (DROP)  booster  module  to  simulate  packet  error.  The  DROP  booster  is  a  single 
element  booster  and  should  be  installed  on  a  network  node  along  the  network  path  of 
communication.  The  network  node  with  DROP  booster  setup  will  drop  packets  (instead  of 
forwarding  packets)  based  on  a  specified  percentage. 

The  forward  erasure  correction  booster  is  implemented  by  having  one  system  with  an  FZC 
module  doing  the  encoding  and  another  system  with  an  FZC  module  doing  the  decoding.  The 
encoder  system  generates  parity  packets  and  inserts  them  into  the  data  stream.  The  decoder 
system  uses  the  minimum,  necessary  number  of  received  packets  (some  original  packets  and 
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some  parity  packets,  assuming  some  lost  packets)  to  reconstruct  the  original  data  stream.  For 
example,  with  FZC:k-h  parameter,  when  forwarding  k  data  packets  from  the  sender,  the  encoder 
adds  h  parity  packets  and  transmits  them  all.  When  receiving  packets,  the  decoder  reconstructs 
the  original  k  data  packets  from  any  k  packets  of  received  packets,  which  might  be  less  than  or 
equal  to  k+h  but  must  be  greater  than  or  equal  to  k,  and  forwards  the  reconstructed  k  data  packets 
to  the  destination  receiver  [4].  If  the  number  of  corrupted  or  missed  packets  is  greater  than  h, 
then  the  reconstruction  of  the  original  k  packets  cannot  be  done  and  retransmission  must  be 
performed.  When  encoding  to  generate  packets,  the  FZC  booster  adds  16  bytes  of  its  overhead 
information  to  every  packet. 

Because  of  the  16-byte  overhead  of  FZC,  the  network  packet  size  might  exceed  the  maximum 
transfer  unit  (MTU)  of  the  Ethernet  interface,  1500  bytes  (1460  bytes  of  payload  and  40  bytes  of 
TCP/IP  header).  Therefore,  we  need  to  use  the  packet  resizer  booster,  MSS,  to  constraint  the 
maximum  data  packet  size  of  TCP/IP  by  modifying  the  advertisement  of  the  maximum  segment 
size  of  TCP  protocol  during  the  TCP’s  initial  three-way  handshake.  To  maintain  the  MTU  at 
1500  bytes,  we  use  the  MSS  booster  to  reduce  the  normal  maximum  segment  size  by  only 
16  bytes,  which  compensates  for  the  16-byte  overhead  of  FZC.  Therefore,  in  the  experiment, 
with  the  use  of  MSS  and  FZC  boosters,  the  actual  maximum  data  packet  size  is  1432  bytes  after 
excluding  overheads. 

2.3  TTCP 

The  protocol  boosters  have  some  limitations  that  prevent  them  from  working  properly  with  some 
TCP/IP  applications  such  as  file  transfer  protocol  (FTP)  software.  Therefore,  to  test  data 
transmission,  we  used  the  program  TTCP,  which  is  public  domain  software  and  works  properly 
with  the  protocol  boosters  on  a  Linux  platform.  TTCP  can  time  the  transmission  and  reception 
rate  of  data  transfer  between  two  systems  using  either  UDP  or  TCP  protocol.  In  the  experiment, 
we  used  TTCP  in  TCP  mode  to  measure  the  data  transfer  rate  over  two  nodes  using  Linux 
operating  systems.  We  notice  that  on  every  data  transfer,  the  transmission  rate  is  slightly  higher 
than  the  reception  rate.  For  consistency  and  completeness  of  the  data  transfer,  we  choose 
reception  rate  as  the  data  transfer  rate. 


3.  Experiment 


3.1  Setup 

Figure  1  depicts  the  setup  of  the  experiment.  The  two  end  systems  of  the  communication  test  are 
Linux  workstations,  Sender  and  Receiver  with  IP  addresses  172.31.1.40  and  172.16.0.40, 
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respectively.  The  gateway  routers  for  the  two  LANs,  S  and  R,  which  are  100-Mbps  Ethernet 
networks,  are  Linux  systems  with  protocol  boosters,  called  Linux-boosterl  and  Linux-boosterO, 
respectively.  Those  gateways  are  in  turn  linked  with  a  10-Mbps  Ethernet  connection  to  Cisco 
1600  routers,  Routerl  and  RouterO.  The  Routerl  connects  to  a  Rockwell  MSU  through  an  RS449 
interface.  The  RouterO  has  ability  to  connect  to  the  USA  National  ISDN.  The  WAN  connection 
using  the  Inmarsat  communication  channel  and  ISDN  links  the  two  Cisco  routers  together  (two 
LANs,  192.168.1.0  and  192.168.0.0).  The  Inmarsat  service  used  for  the  experiment  is  a  64-kbps 
digital  data  channel.  The  data  transmission  travels  from  Sender,  to  Linux-boosterl,  to  Routerl,  to 
MSU,  up  to  the  Inmarsat  AOR-W  satellite,  down  to  the  LES  of  COMSAT  Mobile 
Communications,  to  the  USA  national  ISDN  phone  network,  to  RouterO,  to  Linux-boosterO,  and 
to  Receiver.  There  are  no  other  network  nodes  on  any  LANs  of  the  experiment  to  affect  the  data 
communication  of  Sender  and  Receiver. 


Inmarsat  satellite 


MSU 


serial  link  (20-foot,  mull-modem  cable) 

(simulate  a  clear  charnel  for  comp  arison)  i 


10  Mbps 


connection 


10  Mbps 


connection 


172.31.1.40 
Linux  with  TT  CP 


172.16.0.40 
Linux  with  TT  CP 


Figure  1.  Experiment  setup. 

To  simulate  a  clear  channel  for  comparison,  we  use  a  null-modem  serial  link  to  connect  Routerl 
and  RouterO  (Cisco  routers).  The  null-modem  serial  link  replaces  the  Inmarsat-ISDN  link.  The 
bandwidth  of  the  serial  link  of  two  Cisco  routers  is  set  to  64  kbps,  which  is  the  same  bandwidth 
of  the  Inmarsat  channel.  The  same  point-to-point  protocol  (PPP)  encapsulation  is  used  on  the 
Cisco  routers  for  the  serial  link  and  the  Inmarsat-ISDN  link. 
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3.2  Booster  Parameters 

As  determined  in  section  2.2,  when  using  MSS  and  FZC  boosters,  the  maximum  data  packet  size 
that  can  be  used  for  data  transmission  is  1432  bytes.  Next,  we  need  to  determine  the  optimum 
data  packet  size  and  data-parity  ratio  to  use  in  the  Inmarsat-ISDN  channel,  but  we  do  not  know 
how  bad  or  good  the  channel  is.  We  assume  that  the  ISDN  segment  link  of  the  channel  is  clean 
because  it  is  digital  and  wired  communication.  Therefore,  we  tune  parameters  to  best  fit  the 
satellite  link.  Because  the  forward  erasure  correction  booster  reconstructs  the  entire  corrupted  or 
lost  packet  rather  than  correcting  some  individual  bits  of  the  packet,  we  decided  to  use  the  largest 
data  packet  size,  which  is  1432  bytes,  to  minimize  the  overhead  of  data  transmission.  Also,  the 
findings  of  the  experiment  of  Bakin,  Joa-Ng,  and  McAuley  [5]  indicate  that  reducing  packet  size 
has  very  little  effect  on  the  throughput  data  rate  over  a  geostationary  satellite  link.  Hence,  with 
all  data  and  network  overhead,  the  network  packet  size  (Ethernet  packet  size)  is  1500  bytes. 

Because  the  Inmarsat  service  is  very  costly  (~$10/min)  and  there  are  many  combinations  of  data 
and  parity  that  can  be  used  for  FZC  to  test  the  satellite  link,  we  designed  a  packet-error 
simulation  by  using  DROP  booster  and  the  serial  link.  We  assume  that  the  null-modem  serial 
connection  between  Cisco  routers  is  error  free  (during  the  time  of  the  experiment).  The  DROP 
booster  is  installed  on  the  same  machine  that  encodes  FZC  packets,  Linux-boosterl.  We  use  the 
DROP  booster  to  drop  packets  to  simulate  packet  losses.  The  packet  error  rate  (PER)  can  be 
derived  approximately  from  the  bit  error  rate  (BER)  by  the  fonnula:  PER  =  BER  x  Packet  Size. 
For  example,  the  PER  corresponding  to  a  le-6  BER  with  a  packet  size  of  1500  bytes  (12000  bits) 
is  0.012  or  1.2%.  To  simulate  packet  transmission  errors,  we  let  the  DROP  booster  randomly 
drop  packets  based  on  specified  percentages  corresponding  to  the  desired  PERs. 

We  perform  the  5-MB  data  transmission  using  a  data  packet  size  of  1432  bytes  (or  network 
packet  size  of  1500  bytes)  for  no  FZC  and  4  FZC  cases:  FZC:4-1,  FZC:3-1,  FZC:3-2,  and 
FZC:  1-4.  We  plot  the  data  rates  of  cases  against  the  percentage  of  packet  drop,  as  depicted  in 
Figure  2.  We  notice  that  FZC:4-1  has  the  best  data  rate  among  other  FZCs  for  packet-drop 
percentage  below  23%,  which  corresponds  to  a  BER  of  1.9e-5.  No  transmissions  with  FZC  are 
any  better  than  the  transmission  without  FZC  and  with  a  BER  less  than  1.9e-5.  Therefore,  we 
choose  the  FZC:4-1  parameter  to  test  the  effect  of  the  protocol  boosters  on  the  Inmarsat  satellite 
link. 

We  should  note  that  a  router  having  different  interface  speeds  can  drop  packets  if  the  fast 
interface  passes  to  the  slow  interface  too  many  packets  that  the  slow  interface  cannot  handle.  In 
the  experiment,  the  Linux-boosterO  or  Linux-boosterl  has  two  interfaces  with  speeds  of 
100  Mbps  and  10  Mbps.  At  the  RouterO  and  Router  1,  there  are  two  different  speed  interfaces, 

10  Mbps  and  64  kbps.  Although  cache  buffer  and  flow  control  of  TCP/IP  can  mitigate  the 
problem,  packet  drops  can  still  happen. 
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Data  rates  for  FZC  booster  cases 
(based  on  5  MB  data  transmission) 


no  FZC 
FZC:  4-1 
FZC:  3-1 

- FZC:  3-2 

FZC:  1-4 


0  0.8  5.0  10.0  14.2  16.7  19.2  21.7  24.2  (IE-6) 

BER 


Figure  2.  Packet  error  simulation. 


The  constraints  of  maximum  data  packet  size  of  1432  bytes  and  the  transmission  of  encoded 
FZC:4-1  packets  are  negotiated  and  performed  by  the  Linux-boosterO  and  Linux-boosterl.  The 
Sender  and  Receiver  are  unaware  of  all  actions  of  the  protocol  boosters. 

3.3  Results 

In  the  experiment,  we  tested  the  transmission  of  1-MB,  5-MB,  and  10-MB  data  through  the 
Inmarsat  satellite  link  and  through  the  serial  link.  We  also  used  the  FZC  booster  with  4-1 
parameter  ( 1  parity  packet  for  every  4  data  packets)  to  test  the  transmissions  of  the  same  set  of 
data  and  links.  All  the  tests  were  performed  under  fair  weather  conditions  (sunny  or  cloudy,  but 
not  rainy)  and  temperatures  ranging  from  typical  winter  season  temperatures  to  typical  summer 
season  temperatures. 

Table  1  lists  the  results  of  transmission  times  for  all  cases.  The  serial  link  is  assumed  to  be  error 
free  (for  the  duration  of  the  experiment)  because  it  uses  a  wired  Cisco  serial  connection  with  a 
wire  length  of  20  ft.  It  is  used  as  a  reference  for  comparison.  Table  2  shows  the  data  rate 
comparison  with  the  5-MB-serial-no-boosters  case  for  all  cases. 


Table  1.  Transmission  time  (seconds)  using  TTCP. 


Link  types 

Data  sizes 

1  MB 

5  MB 

10  MB 

serial  -  no  boosters 

137.89 

689.39 

1378.90 

serial  -FZC:4-1 

173.12 

864.82 

1729.41 

Inmarsat  -  no  boosters 

138.98 

690.64 

1380.35 

Inmarsat  -  FZC:4-1 

173.67 

865.64 

1730.09 
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Table  2.  Data  rate  comparison  with  5  MB-serial-no-boosters 
transmission. 


Link  types 

Data  sizes 

1  MB 

5  MB 

10  MB 

serial  -  no  boosters 

99.99% 

100% 

99.99% 

serial  -FZC:4-1 

79.64% 

79.71% 

79.73% 

Inmarsat  -  no  boosters 

99.21% 

99.82% 

99.89% 

Inmarsat  -  FZC:4- 1 

79.39% 

79.64% 

79.69% 

Figure  3  shows  that  the  data  transmission  rate  over  the  serial  link  without  boosters  is  almost 
constant  regardless  of  the  size  of  the  data.  The  results  also  show  that  the  data  transmission  over 
the  Inmarsat  without  boosters  is  very  close  to  that  of  the  error- free  channel  (more  than  99%). 
When  comparing  the  data  transmission  rate  of  the  Inmarsat  with  boosters  and  the  rate  of  the 
serial  link  with  boosters,  we  notice  the  same  closeness  (more  than  99.5%).  This  closeness  in  the 
transmission  rates  of  Inmarsat  and  serial  link  in  various  data  sizes  and  with  or  without  boosters 
indicates  that  their  performance  is  almost  the  same.  Hence,  the  64-kbps  digital  data  channel  of 
Inmarsat  is  very  clear  and  stable  with  a  very  low  BER. 


Transmission  rates  of  various  data  sizes 


I 


o3  _ 

a 


60.84  60.36 

48.46 


48.30 


60.84  60.73 

48.50 


48.45 


60.84  60.77 

48.51 


48.49 


1  MB 


10  MB 


5  MB 
Data  sizes 

□  serial  -  no  boosters  □  serial  -  FZC:4-1  □  Inmarsat  -  no  boosters  ■  Inmarsat  -  FZC:4.1 


Figure  3.  Transmission  result. 

Clearly,  based  on  the  data  collected,  the  protocol  boosters  do  not  improve  the  performance  of 
TCP  over  the  satellite  link.  The  transmission  rate  using  boosters  only  achieves  <80%  of  the  data 
rate  without  using  them.  The  low  data  rate  performance  associated  with  boosters  in  either  serial 
or  Inmarsat  link  clearly  indicates  that  for  a  very  low  BER  channel,  the  extra  FZC  parity  packets 
just  add  to  the  overhead  of  transmission. 

3.4  Discussion 

The  ratio  of  parity  packet  over  data  packet  for  using  FZC:4-1  is  0.25  or  25%;  therefore,  to  see 
any  benefits  of  using  FZC:4-1  booster,  the  PER  should  be  greater  than  0.25  or  25%.  Indeed,  our 
packet  error  simulation  plotted  in  Figure  2  confirms  this  point  as  shown  at  23%  and  26%. 
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We  also  notice  that  in  Figure  2,  with  a  PER  of  6%  (or  BER  of  5e-6)  or  less,  the  reduction  of  data 
transmission  rates  of  FZC  cases,  except  the  FZC:  1-4  case,  scale  with  the  percentage  of  parity 
packets  in  the  total  transmitted  packets  (data  and  parity)  when  compared  with  data  rate  of  no 
FZC  case.  For  example,  for  the  FZC:4-1  booster  (one  parity  packet  for  every  four  data  packets), 
the  percentage  of  parity  is  20%,  and  the  throughput  reduction  is  20%  compared  to  no  FZC  case. 
We  don’t  know  why  the  FZC:  1-4  case  performs  differently,  but  we  did  have  to  prepare  the  FZC 
booster  differently  for  the  FZC:  1-4  case  as  instructed  by  the  author  of  the  protocol  booster 
software.  We  suspect  that  there  are  errors  (operator  or  software)  in  the  FZC:  1-4  case  because  its 
data  rate  did  not  perform  as  expected  for  higher  PER.  This  finding  of  the  simulation  indicates 
that  for  a  channel  with  low  BER  (even  with  5e-6),  the  FZC  booster  does  not  boost  the  throughput 
but  causes  throughput  reduction  based  on  the  percentage  of  parity  encoded.  This  finding  was  also 
reflected  on  the  data  collected  in  our  experiment  for  throughput  perfonnance  of  serial  link  and 
Inmarsat  link.  With  this,  we  can  conclude  that  the  Inmarsat  link  has  a  very  low  BER  because  its 
throughput  performance  is  very  close  to  the  throughput  of  the  serial  link.  Also,  because  the 
Inmarsat  channel  perfonned  consistently  for  the  long  duration  of  10-MB  data  transmission 
(29  min),  we  believe  that  there  is  little  error  bursting  in  the  channel. 

We  further  tested  the  effect  of  parity  percentage  on  the  throughput  reduction  for  the  Inmarsat 
link  by  varying  FZC  booster  parameters,  as  shown  in  Table  3.  As  expected,  the  test  does  show 
that  for  a  very  clear  channel,  the  bandwidth  used  for  forward  error  correction  is  lost  (because 
there  are  very  little  of  errors  to  correct)  and  reduces  the  available  bandwidth  of  the  channel  for 
data  transmission  with  that  same  amount.  Remarkably,  the  throughput  reduction  still  follows  the 
trend  for  the  percentage  of  parity  at  0.5,  1,  and  2%.  With  this  test,  we  can  again  confirm  that  the 
Inmarsat-ISDN  channel  is  nearly  an  error-free  link.  Also,  based  on  this  result,  we  should  note 
that  the  percentage  of  parity  encoded  by  the  FZC  booster  will  limit  the  maximum  throughput  rate 
of  data  transmission  regardless  of  how  good  or  bad  the  channel  is.  For  example,  with  FZC:4-1, 
the  percentage  of  parity  is  20%;  thus  the  maximum  throughput  rate  for  the  data  transmission 
using  FZC:4-1  booster  can  only  be  80%  of  the  throughput  data  rate  for  the  error- free 
transmission  on  the  same  channel. 


Table  3.  Reduction  in  data  rate  with  increase  parity  on  the  Inmarsat  link. 


FZC 

Parameters 

Percentage 

of 

Parity 

5-MB 

Transmission 

Time 

(s) 

Computed 
Throughput 
Data  Rate 
(kbps) 

Percentage 
Reduction  Of 
Throughput  Data 
Rate 

No  booster 

0% 

690.64 

60.73 

0.00% 

199-1 

0.5% 

694.75 

60.37 

0.59% 

99-1 

1% 

698.36 

60.06 

1.11% 

49-1 

2% 

705.02 

59.49 

2.04% 

19-1 

5% 

727.59 

57.65 

5.08% 

9-1 

10% 

768.78 

54.56 

10.16% 

4-1 

20% 

865.64 

48.45 

20.22% 

3-1 

25% 

923.58 

45.41 

25.22% 

3-2 

40% 

1158.00 

36.22 

40.36% 

1-1 

50% 

1383.12 

30.32 

50.07% 
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Although  our  communication  channel  is  only  64  kbps,  the  throughput  data  rate  of  data 
transmission  using  TTCP  can  achieve  60.7  kbps.  A  bandwidth  of  <4  kbps  (or  6.25%)  is  used  for 
the  overhead  of  TCP/IP.  We  notice  that  there  are  small  fluctuations  on  throughput  rates  for  the 
use  of  boosters  on  both  channels.  The  fluctuation  can  be  due  to  the  use  of  some  CPU  time  to  do 
FZC  encoding  and  decoding  on  the  Linux-boosterO  and  Linux-boosterl,  which  act  as  routers. 
The  small  fluctuation  on  the  throughput  rate  of  the  Inmarsat-ISDN  link  without  boosters  can  be 
attributed  to  the  long  delay  and  processing  of  many  different  pieces  of  equipment  (e.g.,  MSU, 
Inmarsat  satellite,  LES,  WorldcomMCI  ISDN  switch,  and  Verzion  switch).  Overall,  these 
fluctuations  are  insignificant  and  are  minimized  on  average  for  long  durations  of  transmission  as 
seen  in  the  10-MB  data  transmission.  However,  a  very  windy  condition  can  affect  the  standing 
position  of  an  Inmarsat  MSU  (which  requires  steadiness);  this,  in  turn,  can  cause  fluctuations  on 
the  Inmarsat  service. 


4.  Conclusion 


Our  experiment  has  shown  a  versatile  way  of  using  the  Inmarsat  communication  service  as  a 
WAN  connection  to  link  a  mobile  LAN  to  the  home  network  from  almost  anywhere  on  the  earth. 
Our  analysis  also  showed  that  the  Inmarsat-ISDN  link  behaves  almost  like  the  null-modem  serial 
link  (very  low  BER)  under  good  weather  conditions.  The  protocol  boosters  do  not  improve  the 
communication  for  this  type  of  channel  but  will  limit  the  maximum  throughput  data  transmission 
rate  of  the  channel  based  on  the  proportion  of  parity  generated  by  the  forward  erasure  correction 
booster. 
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